SOLID ist ein Akronym für eine Gruppe von fünf guten Prinzipien (Regeln) in der Computerprogrammierung. SOLID ermöglicht es Programmierern, Code zu schreiben, der später leichter zu verstehen und zu ändern ist. SOLID wird häufig bei Systemen verwendet, die ein objektorientiertes Design verwenden.
Lassen Sie uns die SOLID-Prinzipien am Beispiel eines Fahrzeugs erklären. Stellen Sie sich vor, wir entwerfen ein System zur Verwaltung verschiedener Fahrzeugtypen, wie Autos und Elektroautos, für einen Transportdienst.

S - Single-Responsibility-Prinzip (SRP)

Fahrzeugbeispiel: Stellen Sie sich vor, Sie hätten ein Auto. Es ist für das Fahren verantwortlich, sollte aber nicht für die Durchführung seiner eigenen Wartungsarbeiten (wie Ölwechsel oder Reifenwechsel) verantwortlich sein. Dafür ist stattdessen ein eigener Mechaniker verantwortlich.
Erläuterung: In unserem Code sollte die Fahrzeugklasse nur Dinge verarbeiten, die sich auf das Fahrzeug selbst beziehen, wie etwa die Speicherung von Marke und Modell. Wenn wir die Wartung verwalten müssen, erstellen wir dafür eine separate Wartungsklasse. Auf diese Weise hat jede Klasse eine Aufgabe oder Verantwortung, was die Verwaltung des Codes erleichtert.

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end
end

class Maintenance
  def initialize(vehicle)
    @vehicle = vehicle
  end

  def perform_maintenance
    puts "Performing maintenance on #{@vehicle.make} #{@vehicle.model}"
  end
end

O - Offenes/Geschlossenes Prinzip (OCP)

Fahrzeugbeispiel: Angenommen, Sie haben ein einfaches Auto und möchten nun ein Elektroauto zu Ihrem System hinzufügen. Sie sollten die bestehende Fahrzeugklasse nicht ändern müssen, um Funktionen für Elektroautos hinzuzufügen. Stattdessen können Sie die bestehende Funktionalität erweitern, indem Sie eine neue Klasse für Elektroautos erstellen.
Erläuterung: Die Fahrzeugklasse ist für Erweiterungen geöffnet (Sie können neue Fahrzeugtypen wie ElectricVehicle erstellen), sie ist jedoch für Änderungen geschlossen (Sie müssen die Fahrzeugklasse selbst nicht ändern, um neue Typen hinzuzufügen).

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def description
    "#{@make} #{@model}"
  end
end

class ElectricVehicle 





  
  
  L - Liskov-Substitutionsprinzip (LSP)


Fahrzeugbeispiel: Stellen Sie sich vor, Sie verfügen über eine Fahrzeugflotte und können jedes normale Auto problemlos durch ein Elektroauto ersetzen. Beide sollten in der Lage sein, ihre Grundfunktion „Fahren“ auszuführen, ohne das System zu beschädigen.
Erklärung: Jede Unterklasse (wie ElectricVehicle) sollte in der Lage sein, ihre übergeordnete Klasse (Vehicle) zu ersetzen, ohne das Verhalten des Programms zu ändern. Dadurch wird sichergestellt, dass unser Code verschiedene Fahrzeugtypen auf die gleiche Weise verarbeiten kann.


class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def drive
    puts "Driving the #{@make} #{@model}"
  end
end

class ElectricVehicle 





  
  
  I - Interface-Segregationsprinzip (ISP)


Fahrzeugbeispiel: Stellen Sie sich vor, Sie haben verschiedene Fahrzeugtypen: Einige können aufgeladen werden (wie Elektroautos), andere können nur gefahren werden (wie Benzinautos). Sie möchten nicht, dass sich ein Benzinauto mit Lademethoden auseinandersetzen muss.
Erläuterung: Klassen sollten nur die Schnittstellen (oder Verhaltensweisen) implementieren, die sie benötigen. Beispielsweise könnte ein Elektrofahrzeug sowohl fahrbare als auch aufladbare Schnittstellen implementieren, während ein normales Fahrzeug nur fahrbare Schnittstellen implementiert.


module Drivable
  def drive
    raise NotImplementedError, "This #{self.class} cannot drive"
  end
end

module Chargeable
  def charge
    raise NotImplementedError, "This #{self.class} cannot be charged"
  end
end

class Vehicle
  include Drivable

  def initialize(make, model)
    @make = make
    @model = model
  end

  def drive
    puts "Driving the #{@make} #{@model}"
  end
end

class ElectricVehicle 





  
  
  D - Abhängigkeitsinversionsprinzip (DIP)


Fahrzeugbeispiel: Stellen Sie sich vor, ein Auto könnte verschiedene Motortypen haben: einen Benzinmotor oder einen Elektromotor. Anstatt direkt von einem bestimmten Motortyp abhängig zu sein, sollte das Auto von einer allgemeineren Motorschnittstelle abhängig sein, damit es jeden Motortyp verwenden kann.
Erläuterung: High-Level-Module (wie das Fahrzeug) sollten nicht von Low-Level-Modulen (wie GasEngine oder ElectricEngine) abhängen. Beide sollten von Abstraktionen abhängen (wie eine Engine-Schnittstelle). Dies macht das System flexibler und einfacher zu ändern.


class Engine
  def start
    raise NotImplementedError, "This #{self.class} cannot start"
  end
end

class GasEngine 



Indem wir die SOLID-Prinzipien in diesem Fahrzeugbeispiel befolgen, können wir ein System aufbauen, das einfach zu warten, zu erweitern und an neue Anforderungen anzupassen ist.

LinkedIn: https://www.linkedin.com/in/anandsoni11/